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IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) 
Abstract 


When Internet Key Exchange Protocol version 2 (IKEv2) is used for 
remote VPN access (client to VPN gateway), the gateway assigns the 
client an IP address from the internal network using IKEv2 
configuration payloads. The configuration payloads specified in RFC 
4306 work well for IPv4 but make it difficult to use certain features 
of IPv6. This document specifies new configuration attributes for 
IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, 
enabling all features of IPv6 to be used with the client-gateway 
"virtual link". 


Status of This Memo 
This document is not an Internet Standards Track specification; it is 
published for examination, experimental implementation, and 


evaluation. 


This document defines an Experimental Protocol for the Internet 
community. This document is a product of the Internet Engineering 


Task Force (IETF). It represents the consensus of the IETF 
community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Not 


all documents approved by the IESG are a candidate for any level of 
Internet Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5739. 
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Te Introduction and Problem Statement 


In typical remote access VPN use (client to VPN gateway), the client 
needs an IP address in the network protected by the security gateway. 
IKEv2 includes a feature called "configuration payloads" that allows 
the gateway to dynamically assign a temporary address to the client 
[IKEv2]. 


For IPv4, the message exchange would look as follows: 


Client Gateway 
HDR(IKE_SA_INIT), SAil, KEi, Ni --> 
<-- HDR(IKE_SA_INIT), SArl, KEr, Nr, [CERTREQ] 


HDR(IKE_AUTH), 
SK { IDi, CERT, [CERTREQ], AUTH, [IDr], 
CP (CFG_REQUEST) = 
{ INTERNAL _IP4_ADDRESS(), 
INTERNAL_1P4_DNS() }, SAi2, 
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255), 
TSr (0, 0-65535, 0.0.0.0-255.255.255.255) ) ==> 


<--= HDR(IKE_AUTH), 
SK { IDr, CERT, AUTH, 
CP (CFG_REPLY) = 
{ INTERNAL_IP4_ ADDRESS (192.0.2.234), 
INTERNAL_IP4_ DNS (198.51.100.33) ), 
SAr2, 
TSi = (0, 0-65535, 192.0.2.234-192.0.2.234), 
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } 


Figure 1: IPv4 Configuration 
The IPv4 case has been implemented by various vendors and, in 


general, works well. IKEv2 also defines almost identical 
configuration payloads for IPv6: 
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Client Gateway 


HDR (IKE_AUTH), 
SK { IDi, CERT, [CERTREQ], AUTH, [IDr], 
CP (CFG_REQUEST) = 
{ INTERNAL IP6_ADDRESS(), 
INTERNAL _IP6_DNS() }, SAi2, 
TSi = (0, 0-65535, 
0:0:0:0:0:0:0:0 — 
FRFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF), 


TSr = (0, 
0-65535, 0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) } --> 
<-—= HDR(IKE_AUTH), 


SK { IDr, CERT, AUTH, 
CP (CFG_REPLY) = 
{ INTERNAL _IP6_ADDRESS (2001:DB8:0:1:2:3:4:5, 


64), 
INTERNAL _IP6_DNS (2001:DB8:9:8:7:6:5:4) }, 
SAr2, 
TSi = (0, 0-65535, 
200 1-:DB8:: 0% 1:02: 3:64::5 = 
2001:DB8:0:1:2:3:4:5), 


TSr = (0, 0-65535, 
0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) ) 


Figure 2: IPv6 Configuration 


In other words, IPv6 is basically treated as IPv4 with larger 
addresses. As noted in [RFC4718], this does not fully follow the 
"normal IPv6 way of doing things", and it complicates or prevents 
using certain features of IPv6. Section 3 describes the limitations 
in detail. 


This document specifies new configuration attributes for IKEv2 that 
allows the VPN gateway to assign IPv6 prefixes to clients, enabling 
all features of IPv6 to be used with the client-gateway "virtual 
link". 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [KEYWORDS]. 
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3; 


3 


When messages containing IKEv2 payloads are described, optional 
payloads are shown in brackets (for instance, "[FOO]"); a plus sign 
indicates that a payload can be repeated one or more times (for 
instance, "FOO+"). 


This document uses the term "virtual interface" when describing how 
the client uses the IPv6 address (es) assigned by the gateway. While 
existing IPsec documents do not use this term, it is not a new 
concept. In order to use the address assigned by the VPN gateway, 
current VPN clients already create a local "virtual interface", as 
only addresses assigned to interfaces can be used, e.g., as source 
addresses for TCP connections. Note that this definition of 
"interface" is not necessarily identical with what some particular 
implementations call "interface". 


Current Limitations and Goals 


This section describes the limitations of the current IPv6 
configuration mechanism and requirements for the new solution. 


.1. Multiple Prefixes 


In Figure 2, only a single IPv6 address (from a single prefix) is 
assigned. The specification does allow the client to include 
multiple INTERNAL_IP6_ADDRESS attributes in its request, but the 
gateway cannot assign more addresses than the client requested. 


Multiple prefixes are useful for site renumbering, host-based site 

multihoming [SHIM6], and unique local IPv6 addresses [RFC4193]. In 
all of these cases, the gateway has better information on how many 

different addresses (from different prefixes) the client should be 

assigned. 


The solution should support assigning addresses from multiple 
prefixes, without requiring the client to know beforehand how many 
prefixes are needed. 


.2. Link-Local Addresses 


The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6 
addresses of all types are assigned to interfaces, not nodes. [..] 
All interfaces are required to have at least one Link-Local unicast 
address". 


Currently, the virtual interface created by IKEv2 configuration 
payloads does not have link-local addresses. This violates the 
requirements in [IPv6Addr] and prevents the use of protocols that 
require link-local addresses, such as [MLDv2] and [DHCPv6]. 
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The solution should assign link-local addresses to the virtual 
interfaces and allow them to be used for protocols between the VPN 
client and gateway. 


3.3. Interface Identifier Selection 


In the message exchange shown in Figure 2, the gateway chooses the 
interface ID used by the client. It is also possible for the client 
to request a specific interface ID; the gateway then chooses the 
prefix part. 


This approach complicates the use of Cryptographically Generated 
Addresses (CGAs) [CGA]. With CGAs, the interface ID cannot be 
calculated before the prefix is known. The client could first obtain 
a non-CGA address to determine the prefix and then send a separate 
CFG_REQUEST to obtain a CGA address with the same prefix. However, 
this approach requires that the IKEv2 software component provide an 
interface to the component managing CGAs; an ugly implementation 
dependency that would be best avoided. 


Similar concerns apply to other cases where the client has some 
interest in what interface ID is being used, such as Hash-Based 
Addresses [HBA] and privacy addresses [RFC4941]. 


Without CGAs and HBAs, VPN clients are not able to fully use IPv6 
features such as [SHIM6] or enhanced Mobile IPv6 route optimization 
[RFC4866]. 


The solution should allow the VPN client to easily obtain several 
addresses from a given prefix, where the interface IDs are selected 
by the client and may depend on the prefix. 


3.4. Sharing VPN Access 


Some VPN clients may want to share the VPN connection with other 
devices (e.g., from a cell phone to a laptop or vice versa) via some 
local area network connection (such as Wireless LAN or Bluetooth), if 
allowed by the security policy. 


Quite obviously, sharing of VPN access requires more than one address 
(unless NAT is used). However, the current model where each address 
is requested separately is probably complex to integrate with a local 
area network that uses stateless address autoconfiguration 
[AUTOCONF]. Thus, obtaining a whole prefix for the VPN client and 
advertising that to the local link (something resembling [NDProxy]) 
would be preferable. With DHCPv6 prefix delegation [RFC3633], even 
[NDProxy] and associated multi-link subnet issues would be avoided. 
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The solution should support sharing the VPN access over a local area 
network connection when the other hosts are using stateless address 
autoconfiguration. 


3.5. General Goals 
o The solution should avoid periodic messages over the VPN tunnel. 


o Reauthentication should work, where the client can start a new IKE 
Security Association (SA) and continue using the same addresses as 
before. 


o There should be compatibility with other IPsec uses. Configuring 
a virtual IPv6 link (with addresses assigned in IKEv2) should not 
prevent the same peers from using IPsec/IKEv2 for other uses (with 
other addresses). In particular, the peers may have Security 
Policy Database (SPD) entries and Peer Authorization Database 
(PAD) Child SA Authorization Data entries that are not related to 
the virtual link; when a CHILD_SA is created, it should be 
unambiguous which entries are used. 


o There should be compatibility with current IPv6 configuration. 
Although the current IPv6 mechanism is not widely implemented, new 
solutions should not preclude its use (e.g., by defining 
incompatible semantics for the existing payloads). 


o The solution should have clean implementation dependencies. In 
particular, it should not require significant modifications to the 
core IPv6 stack (typically part of the operating system) or 
require the IKEv2 implementor to re-implement parts of the IPv6 
stack (e.g., to have access or control to functionality that is 
currently not exposed by interfaces of the IPv6 stack). 


o Re-use existing mechanisms as much as possible, as described in 
[IPConfig]. Appendix A describes the rationale of why this 
document nevertheless uses IKEv2 configuration payloads for 
configuring the addresses. However, Section 4.1 recommends using 
a DHCPv6 Information-Request message for obtaining other 
configuration information (such as DNS server addresses). 


3.6. Non-Goals 
Mobile IPv6 already defines how it interacts with IPsec/IKEv2 


[RFC4877], and the intent of this document is not to change that 
interaction in any way. 
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3:5 


4. 


4. 


7. Additional Information 


If the VPN client is assigned IPv6 address(es) from prefix(es) that 
are shared with other VPN clients, this results in some kind of 
multi-link subnet. [Multilink] describes issues associated with 
multi-link subnets and recommends that they be avoided. 


The original 3GPP specifications for IPv6 assigned a single IPv6 
address to each mobile phone, resembling current IKEv2 payloads. 
[RFC3314] describes the problems with this approach and caused 3GPP 
to change the specifications to assign unique /64 prefix(es) for each 
phone. 


Due to similar concerns, the IEEE 802.16 IPv6 Convergence Sublayer 
[RFC5121] and Proxy Mobile IPv6 [RFC5213] also assign unique 
prefixes. 
Solution Details 
1. Initial Exchanges 
During IKE_AUTH, the client sends a new configuration attribute, 


INTERNAL_IP6_LINK, which requests a virtual link to be configured. 
The attribute contains the client’s interface ID for the link-local 


address (other addresses may use other interface IDs). Typically, 
the client would also ask for the DHCPv6 server address; this is used 
only for configuration (such as DNS server addresses), not address 
assignment. 


CP (CFG_REQUEST) = 
{ INTERNAL _ IP6_LINK(Client’s Link-Local Interface ID) 
INTERNAL _IP6_DHCP() } 
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 


If the client has sent the INTERNAL_IP6_LINK configuration attribute, 
the VPN gateway SHOULD ignore any INTERNAL_IP6_ADDRESS configuration 
attribute present in the request. 


The VPN gateway MUST choose for itself a link-local interface 
identifier different than the client’s, i.e., accept the link-local 
interface identifier proposed by the client. In case the VPN gateway 
cannot accept the link-local interface identifier the client 
proposed, the VPN gateway MUST fail the IPv6 address assignment by 
including a NOTIFY payload with the INTERNAL_ADDRESS_FAILURE message. 
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The VPN gateway then replies with an INTERNAL_IP6_LINK configuration 
attribute that contains the IKEv2 Link ID (an identifier selected by 
the VPN gateway, treated as an opaque octet string by the client -- 
this will be used for reauthentication and CREATE_CHILD_SA messages), 
the gateway’s link-local interface identifier, and zero or more 
INTERNAL _IP6_PREFIX attributes. The traffic selectors proposed by 
the initiator are also narrowed to contain only the assigned prefixes 
and the client link-local address (FE80::<Client’s Interface ID>) 
identifier. 


CP (CFG_REPLY) = 
{ INTERNAL_IP6_LINK(Gateway’s Link-Local Interface ID, 
IKEv2 Link ID) 
INTERNAL _IP6_PREFIX(Prefix1/64), 


[INTERNAL_IP6_PREFIX (Prefix2/64),...], 
INTERNAL_IP6_DHCP (Address) } 
TSi = ((0, 0-65535, 


FE80::<Client’s Interface ID> - 
FE80::<Client’s Interface ID>) 
(0, 0-65535, 

Prefix1::0 = 
Prefixl::FFFF:FFFF:FFFF:FFFF), 
[(0, 0-65535, 

Prefix2::0 - 

Prefix2::FFFF:FFFF:FFFF:FFFF), ...]) 

TSr = (0, 0-65535, 

0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 


At this point, the client can configure its link-local address 
(FE80::<Client’s Interface ID>) and other non-link-local unicast 
addresses from the assigned prefixes (with any proper interface 
identifier [IPv6Addr]). The VPN gateway MUST NOT simultaneously 
assign the same prefixes to any other client and MUST NOT itself 
configure addresses from these prefixes. Thus, the client does not 
have to perform Duplicate Address Detection (DAD). (This approach is 
based on [IPv6PPP].) 


The prefixes remain valid through the lifetime of the IKE SA (and its 
continuations via rekeying). If the VPN gateway needs to remove a 
prefix it has previously assigned, or assign a new prefix, it can do 
so with reauthentication (either starting reauthentication itself or 
requesting the client to reauthenticate using [RFC4478]). 


The client also contacts the DHCPv6 server. This is the RECOMMENDED 

way to obtain additional configuration parameters (such as DNS server 
addresses), as it allows easier extensibility and more options (such 

as the domain search list for DNS). 
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4.2. Reauthentication 


When the client performs reauthentication (and wants to continue 
using the same "virtual link"), it includes the IKEv2 Link ID given 
by the gateway in the INTERNAL_IP6_LINK attribute. 


CP (CFG_REQUEST) = 
{ INTERNAL IP6_LINK(Client's Link Local Interface ID, 
IKEv2 Link ID) 
INTERNAL _IP6_DHCP() } 

TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 

TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 


At this point, the gateway MUST verify that the client is indeed 
allowed to use the link identified by the IKEv2 Link ID. The same 
situation occurs in [IKEv2] when the client wants to continue using 
the same IPv4 address with the INTERNAL_IP4_ ADDRESS configuration 
attribute. Typically, the gateway would use the Link ID to look up 
relevant local state and compare the authenticated peer identity of 
the IKE_SA with the local state. 


If the client is allowed to continue using this link, the gateway 
replies (see Section 4.1) with the same gateway’s link-local 
interface ID and IKEv2 Link ID as used earlier and sends the IPv6 
prefix(es) associated with this link. Usually, the IPv6 prefix(es) 
will also be the same as earlier, but this is not required. 


If the client is not allowed to continue using this link, the gateway 
treats it as a request for a new virtual link, selects a different 
IKEv2 Link ID value, and replies as in Section 4.1. 


4.3. Creating CHILD_SAs 


When a CHILD_SA is created, the peers need to determine which SPD 
entries and PAD Child SA Authorization Data entries are used for this 
CHILD_SA. In the basic client-to-VPN-gateway uses, the situation is 
simple: all the matching SPD entries and Child SA Authorization Data 
entries are related to the "virtual link" between the VPN client and 
the VPN gateway. However, if the same peers are also using IPsec/ 
IKEv2 for other uses (with addresses not assigned inside IKEv2), they 
would also have SPD entries and PAD Child SA Authorization Data that 
is not related to the virtual link. 


If one of the peers requests a CHILD_SA and proposes traffic 
selectors covering everything (like in Figure 2), should those be 
narrowed to the prefixes configured with INTERNAL_IP6_PREFIX or to 
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the other SPD/PAD entries? While some kind of heuristics are 
possible (see Appendix A for discussion), this document specifies an 
explicit solution: 


The peers MUST include a LINK_ID notification, containing the IKEv2 
Link ID, in all CREATE_CHILD_SA requests (including rekeys) that are 
related to the virtual link. The LINK_ID notification is not 
included in the CREATE_CHILD_SA response or when doing IKE_SA 
rekeying. 


4.4. Relationship to Neighbor Discovery 
Neighbor Discovery [IPv6ND] specifies the following mechanisms: 
Router Discovery, Prefix Discovery, Parameter Discovery, and address 
autoconfiguration are not used, as the necessary functionality is 
implemented in IKEv2. 
Address Resolution, Next-hop Determination, and Redirect are not 
used, as the virtual link does not have link-layer addresses and is a 


point-to-point link. 


Neighbor Unreachability Detection could be used but is a bit 
redundant given IKEv2 Dead Peer Detection. 


Duplicate Address Detection is not needed because this is a point-to- 
point link, where the VPN gateway does not assign any addresses from 
the global unicast prefixes, and the link-local interface identifier 
is negotiated separately. 


Duplicate Address Detection is not needed for global unicast 
addresses formed from the global unicast prefix(es) configured as 
part of the IKEv2 exchange, because this is a point-to-point link, 
where the VPN gateway does not assign any addresses from the global 
unicast prefixes. Duplicate Address Detection may be needed for 
link-local addresses, e.g., when the client configures a link-local 
address as per [RFC4941]. 


Thus, Duplicate Address Detection MAY be skipped for global unicast 
addresses formed from the global unicast prefix(es) configured as 
part of the IKEv2 exchange. However, Duplicate Address Detection for 
link-local unicast addresses MUST be performed as required per some 
other specifications, e.g., [RFC4941]. 
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4. 


D6 


Dis 


5. Relationship to Existing IKEv2 Payloads 


The mechanism described in this document is not intended to be used 
at the same time as the existing INTERNAL_IP6_ADDRESS attribute. For 
compatibility with gateways implementing only INTERNAL_IP6_ADDRESS, 
the VPN client MAY include attributes for both mechanisms in 
CFG_REQUEST. The capabilities and preferences of the VPN gateway 
will then determine which is used. 


All other attributes except INTERNAL_IP6_ADDRESS (and 

INTENAL_ ADDRESS EXPIRY) from [IKEv2] remain valid, including the 
somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of 
[RFC4718] for discussion). 


Payload Formats 
1, INTERNAL_IP6_LINK Configuration Attribute 


The INTERNAL_IP6_LINK configuration attribute is formatted as 
follows: 


af 2 3 
0 1 2: 3-4-5 6 7 8-9-0- 1-2. 3 456 78 901.2345 67 89 0 1 

TOE o a FF - FFF -F -F -F -4+ 
IR] Attribute Type ! Length 

4-+-4-4-4-4-4-4-4-4-4-4-4-4F-4-4F-4-4F-4-F 4 -F 4H -F -F E e 4+ 
| Link-Local | 
| Interface ID | 
a -F E -F - 4 -F E EE E EN 
| | 


IKEv2 Link ID ~ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 


o Reserved (1 bit) - See [IKEv2]. 
o Attribute Type (15 bits) - INTERNAL_IP6_LINK (17). 
o Length (2 octets) - Length in octets of the Value field (Link- 


Local Interface ID and IKEv2 Link ID); 8 or more. 


o Link-Local Interface ID (8 octets) - The Interface ID used for 
link-local address (by the party that sent this attribute). 


o IKEv2 Link ID (variable length) - The Link ID (may be empty when 
the client does not yet know the Link ID). The Link ID is 
selected by the VPN gateway and is treated as an opaque octet 
string by the client. 
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5.2. INTERNAL_IP6_PREFIX Configuration Attribute 


The INTERNAL_IP6_PREFIX configuration attribute is formatted as 
follows: 


1 2 3 

012345678°9012345678°901234567890 1 
+-+-+-+-+-+-+-+-+-+-+-+ O O o O o O o o + + + + 
IR] Attribute Type ! Length 
++ A A O O O O O A O o O o o o o o + + + 
| Prefix | 
d+ A A O O A O O A +++ 
| Prefix Length | 
+-+-+-+-+-+-+-+-+ 


o Reserved (1 bit) - See [IKEv2]. 

o Attribute Type (15 bits) - INTERNAL_IP6_PREFIX (18). 

o Length (2 octets) - Length in octets of the Value field; in this 
case, 17. 

o Prefix (16 octets) - An IPv6 prefix assigned to the virtual link. 


The low-order bits of the prefix field that are not part of the 
prefix MUST be set to zero by the sender and MUST be ignored by 
the receiver. 


o Prefix Length (1 octet) - The length of the prefix in bits; 
usually 64. 


5.3. LINK_ID Notify Payload 


The LINK_ID notification is included in CREATE_CHILD_SA requests to 
indicate that the SA being created is related to the virtual link. 
If this notification is not included, the CREATE_CHILD_SA requests 
are related to the real interface. 


The Notify Message Type for LINK_ID is 16414. The Protocol ID and 
SPI Size fields are set to zero. The data associated with this 
notification is the IKEv2 Link ID returned in the INTERNAL_IP6_LINK 
configuration attribute. 
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6. 


IANA Considerations 


This document defines two new IKEv2 configuration attributes, whose 
values have been allocated from the "IKEv2 Configuration Payload 
Attribute Types" namespace [IKEv2]: 


Multi- 
Value Attribute Type Valued Length Reference 
17 INTERNAL_IP6_LINK NO 8 or more [RFC5739] 
18 INTERNAL _IP6_PREFIX YES 17 octets [RFC5739] 


This document also defines one new IKEv2 notification, whose value 
has been allocated from the "IKEv2 Notify Message Types - Status 
Types" namespace [IKEv2]: 


16414 LINK_ID [RFC5739] 


This document does not create any new namespaces to be maintained by 
IANA. 


Security Considerations 


Since this document is an extension to IKEv2, the security 
considerations in [IKEv2] apply here as well. 


The mechanism described in this document assigns each client a unique 
prefix, which makes using randomized interface identifiers [RFC4941] 
ineffective from a privacy point of view: the client is still 
uniquely identified by the prefix. In some environments, it may be 
preferable to assign a VPN client the same prefix each time a VPN 
connection is established; other environments may prefer assigning a 
different prefix every time for privacy reasons. (This is basically 
a Similar trade-off as in Mobile IPv6 -- using the same Home Address 
forever is simpler than changing it often, but has privacy 
implications.) 
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Appendix A. Design Rationale (Non-Normative) 


This appendix describes some of the reasons why the solution in 
Section 4 was selected and lists some alternative designs that were 
considered but were ultimately rejected. 


Assigning a new IPv6 address to the client creates a new "virtual 
IPv6 interface" and "virtual link" between the client and the 
gateway. We will assume that the virtual link has the following 
properties: 


o The link and its interfaces are created and destroyed by the IKEv2 
process. 


o The link is not an IPsec SA; at any time, there can be zero or 
more IPsec SAs covering traffic on this link. 


o The link is not a single IKE SA; to support reauthentication, it 
must be possible to identify the same link in another IKE SA. 


o Not all IPsec-protected traffic between the peers is necessarily 
related to the virtual link (although in the simplest VPN client- 
to-gateway scenario, it will be). 


Given these assumptions and the goals described in Section 3, it 
seems that the most important design choices to be made are the 
following: 


o What link/subnet model is used; in other words, how relationships 
between VPN clients, IPv6 subnet prefixes, and link-local traffic 
(especially link-local multicast) are organized. 


o How information about the IPv6 prefix(es) is distributed from the 
gateway to the clients. 


o How to ensure unique IPv6 addresses for each client and keep 
forwarding state up-to-date accordingly. 


o How layer 3 access control is done; in other words, where the 
mechanisms for preventing address spoofing by clients are placed 


architecturally. 


Each of these is discussed next in turn. 


Eronen, et al. Experimental [Page 19] 


RFC 5739 IPv6 Configuration in IKEv2 February 2010 


A.l. Link Model 


There are at least three main choices for how to organize the 
relationships between VPN clients, IPv6 subnet prefixes, and link- 
local traffic: 


o Point-to-point link model: each VPN client is assigned one or more 
IPv6 prefixes. These prefixes are not shared with other clients, 
and there is no link-local traffic between different VPN clients 
connected to the same gateway. 


o Multi-access link model: multiple VPN clients share the same IPv6 
prefix. Link-local multicast packets sent by one VPN client will 
be received by other VPN clients (VPN gateway will forward the 
packets, possibly with Multicast Listener Discovery (MLD) snooping 
to remove unnecessary packets). 


o "Router aggregation" link model: one form of "multi-link" subnet 
[Multilink] where multiple VPN clients share the same IPv6 prefix. 
Link-local multicast will not be received by other VPN clients. 


In the multi-access link model, VPN clients who are idle (i.e., not 
currently sending or receiving application traffic) could receive 
significant amounts of multicast packets from other clients 
(depending on how many other clients are connected). This is 
especially undesirable when the clients are battery-powered such as a 
PDA that keeps the VPN connection to corporate intranet active 24/7. 
For this reason, using the multi-access link model was rejected. 


The configuration attributes specified in Section 4 use the point-to- 
point link model. 


A.2. Distributing Prefix Information 
Some types of addresses, such as CGAs, require knowledge about the 
prefix before an address can be generated. The prefix information 
could be distributed to clients in the following ways: 
o IKEv2 messages (configuration payloads) 
o Router Advertisement messages (sent over the IPsec tunnel) 


o DHCPv6 messages (sent over the IPsec tunnel) 


In Section 4, the prefix information is distributed in IKEv2 
messages. 
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A.3. Unique Address Allocation 


In the "multi-access" and "router aggregation" link models (where a 
single IPv6 prefix is shared between multiple VPN clients), 
mechanisms are needed to ensure that one VPN client does not use an 
address already used by some other client. Also, the VPN gateway has 
to know which client is using which addresses in order to correctly 
forward traffic. 


The main choices seem to be the following: 


o Clients receive the address(es) they are allowed to use in IKEv2 
messages (configuration payloads). In this case, keeping track of 
which client is using which address is trivial. 


o Clients receive the address(es) they are allowed to use in DHCPv6 
messages sent over the IPsec tunnel. In case the DHCPv6 server is 
not integrated with the VPN gateway, the gateway may need to work 
as a relay agent to keep track of which client is using which 
address (and update its forwarding state accordingly). 


o Clients can use stateless address autoconfiguration to configure 
addresses and perform Duplicate Address Detection (DAD). This is 
easy to do in a multi-access link model and can be made to work 
with a router aggregation link model if the VPN gateway traps 
Neighbor Solicitation (NS) messages and spoofs Neighbor 
Advertisement (NA) replies. The gateway keeps track of which 
client is using which address (and updates its forwarding state 
accordingly) by trapping these NS/NA messages. 


In the point-to-point link model, the client can simply use any 
address from the prefix, and the VPN gateway only needs to know which 
client is using which prefix in order to forward packets correctly. 


A.4. Layer 3 Access Control 


It is almost always desirable to prevent one VPN client from sending 
packets with a source address that is used by another VPN client. In 
order to correctly forward packets destined to clients, the VPN 
gateway obviously has to know which client is using which address; 
the question is therefore where, architecturally, the mechanisms for 
ingress filtering are placed. 


o Layer 3 access control could be enforced by IPsec Security 
Association Database (SAD) / SPD; the addresses/prefixes assigned 
to a VPN client would be reflected in the traffic selectors used 
in IPsec Security Association and Security Policy Database 
entries, as negotiated in IKEv2. 
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o The ingress filtering capability could be placed outside IPsec; 
the traffic selectors in SAD/SPD entries would cover traffic that 
would be dropped later by ingress filtering. 


The former approach is used by the current IPv4 solution and the 
mechanism specified in Section 4. 


A.5. Other Considerations 
VPN gateway state 


In some combinations of design choices, the amount of state 
information required in the VPN gateway depends not only on the 
number of clients but also on the number of addresses used by one 
client. With privacy addresses and potentially some uses of 
Cryptographically Generated Addresses (CGAs), a single client 
could have a large number of different addresses (especially if 
different privacy addresses are used with different destinations). 


Virtual link identifier 


Reauthentication requires a way to uniquely identify the virtual 
link when a second IKE SA is created. Some possible alternatives 
are the IKE Security Parameter Indexes (SPIs) of the IKE SA where 
the virtual link was "created" (assuming we can't have multiple 
virtual links within the same IKE SA), a new identifier assigned 
when the link is created, or any unique prefix or address that 
remains assigned to the link for its entire lifetime. Section 4 
specifies that the gateway assigns a new IKEv2 Link ID when the 
link is created. The client treats the Link ID as an opaque octet 
string; the gateway uses it to identify relevant local state when 
reauthentication is done. 


Note that the link is not uniquely identified by the IKE peer 
identities (because IDi is often a user identity that can be used 
on multiple hosts at the same time) or the outer IP addresses of 
the peers (due to NAT Traversal and [MOBIKE]). 
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Prefix lifetime 


Prefixes could remain valid either for the lifetime of the IKE SA, 
until explicitly cancelled, or for an explicitly specified time. 
In Section 4, the prefixes remain valid for the lifetime of the 
IKE SA (and its continuations via rekeying but not via 
reauthentication). If necessary, the VPN gateway can thus add or 
remove prefixes by triggering reauthentication. It is assumed 
that adding or removing prefixes is a relatively rare situation, 
and thus this document does not specify more complex solutions 
(such as explicit prefix lifetimes or use of CFG_SET/CFG_ACK) . 


Compatibility with other IPsec uses 


Compatibility with other IPsec uses probably requires that when a 
CHILD_SA is created, both peers can determine whether the CHILD_SA 
applies to the virtual interface (at the end of the virtual link) 
or the real interfaces over which IKEv2 messages are being sent. 
This is required to select the correct SPD to be used for traffic- 
selector narrowing and SA authorization in general. 


One straight-forward solution is to add an extra payload to 
CREATE_CHILD_SA requests, containing the virtual link identifier. 
Requests not containing this payload would refer to the real link 
(over which IKEv2 messages are being sent). 


Another solution is to require that the peer requesting a CHILD_SA 
proposes traffic selectors that identify the link. For example, 
if TSi includes the peer’s "outer" IP address, it’s probably 
related to the real interface, not the virtual one. Or if TSi 
includes any of the prefixes assigned by the gateway (or the link- 
local or multicast prefix), it is probably related to the virtual 
interface. 


These heuristics can work in many situations but have proved 
inadequate in the context of IPv6-in-IPv4 tunnels [RFC4891], 
Provider Provisioned VPNs ([VLINK], [RFC3884]), and Mobile IPv6 


[RFC4877]. Thus, Section 4 includes the virtual link identifier 
in all CREATE_CHILD_SA requests that apply to the virtual 
interface. 


Example of other IPsec uses: 


If a VPN gateway receives a CREATE_CHILD_SA request associated 
with a physical Ethernet interface, requesting an SA for 
(TSi=FE80::something, dst=*), it would typically reject the 
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A.6. 


Ero 


request (or, in other words, narrow it to an empty set) because it 
doesn't have SPD/PAD entries that would allow joe.user@example.com 
to request such CHILD_SAs. 


(However, it might have SPD/PAD entries that would allow 
"neighboring-router.example.com" to create such SAs to protect, 
for example, some routing protocol that uses link-local 
addresses.) 


However, the virtual interface created when joe.user@example.com 
authenticated and sent INTERNAL _IP6_LINK would have a different 
SPD/PAD, which would allow joe.user@example.com to create this SA. 


Alternative Solution Sketches 
1. Version -00 Sketch 


The -00 version of this document contained the following solution 
sketch, which is basically a combination of (1) a point-to-point link 
model, (2) prefix information distributed in Neighbor Advertisements, 
and (3) access control enforced outside IPsec. 


1. During IKE_AUTH, the client sends a new configuration attribute, 
INTERNAL_IP6_LINK, which requests a virtual link to be created. 
The attribute contains the client's interface ID for the link- 
local address (other addresses may use other interface IDs). 


CP (CFG_REQUEST) = 
{ INTERNAL IP6_LINK(Link-Local Interface ID) ) 
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 = 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 


The VPN gateway replies with its own link-local interface ID (which 
has to be different from the client’s) and an IKEv2 Link ID (which 
will be used for reauthentication). 


CP (CFG_REPLY) = 
{ INTERNAL IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) } 
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 = 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 
TSE = (0, 0-65535, 0:0:0:0:0:0:0:0 = 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 


At this point, both peers configure the virtual interface with the 
link-local addresses. 
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2. The next step is IPv6é stateless address autoconfiguration, that 
is, Router Solicitation and Router Advertisement messages sent 
over the IPsec SA. 


ESP (Router Solicitation: 
src=::, 
dst=FF02:0:0:0:0:0:0:2) =-> 


<-- ESP (Router Advertisement: 
src=FE80::<Gateway’s Interface ID> 
dst=FF02:0:0:0:0:0:0:1, 
Prefixl, [Prefix2...]) 


After receiving the Router Advertisement, the client can configure 
unicast addresses from the advertised prefixes, using any proper 


interface ID. The VPN gateway does not simultaneously assign the 
same prefixes to any other client and does not itself configure 
addresses from these prefixes. Thus, the client does not have to 


perform Duplicate Address Detection (DAD). 


3. Reauthentication works basically the same way as in Section 4; 
the client includes the IKEv2 Link ID in the INTERNAL _IP6_LINK 
attribute. 

4. Creating and rekeying IPsec SAs works basically the same way as 


in Section 4.3; the client includes the IKEv2 Link ID in those 
CHILD_SA requests that are related to the virtual link. 


Comments: This was changed in the -01 version of this document based 
on feedback from VPN vendors; while the solution looks nice on paper, 
it is claimed to be unnecessarily complex to implement when the IKE 
implementation and IPv6 stack are from different companies. 
Furthermore, enforcing access control outside IPsec is a significant 
architectural change compared to current IPv4 solutions. 


A.6.2. Router Aggregation Sketch #1 


Hemant Singh helped sketch the following solution during the IETF 70 
meeting in Vancouver. It combines (1) the router aggregation link 
model, (2) prefix information distributed in IKEv2 messages, (3) 
unique address allocation with stateless address autoconfiguration 
(with VPN gateway trapping NS messages and spoofing NA replies), and 
(4) access control enforced (partly) outside IPsec. 


1. During IKE_AUTH, the client sends a new configuration attribute, 
INTERNAL_IP6_LINK, which requests a virtual link to be created. 
The attribute contains the client’s interface ID for the link- 
local address (other addresses may use other interface IDs). 
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CP (CFG_REQUEST) = 
{ INTERNAL IP6_LINK(Link-Local Interface ID) } 
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 = 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 


The VPN gateway replies with its own Link-Local Interface ID (which 
has to be different from the client’s), an IKEv2 Link ID (which will 
be used for reauthentication and CREATE_CHILD_SA messages), and zero 
or more INTERNAL_IP6_PREFIX attributes. The traffic selectors 
proposed by the initiator are also narrowed to contain only the 
assigned prefixes (and the link-local prefix). 


CP (CFG_REPLY) = 
{ INTERNAL IP6_LINK(Link-Local Interface ID, IKEv2 Link ID), 
INTERNAL _IP6_PREFIX(Prefix1/64), 
[INTERNAL_IP6_PREFIX(Prefix2/64),...] } 
TSi = ((0, 0-65535, 
FE80::<Client’s Interface ID> - 
FE80::<Client’s Interface ID>) 
(0, 0-65535, 
Prefix1::0 - 
Prefixl::FFFF:FFFF:FFFF:FFFF), 
[(0, 0-65535, 
Prefix2::0 - 
Prefix2::FFFF:FFFF:FFFF:FFFF), ...]) 
TSr = (0, 0-65535, 
0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 


2. The client now configures tentative unicast addresses from the 
prefixes given by the gateway, and performs Duplicate Address 
Detection (DAD) for them. 


The Neighbor Solicitation messages are processed by the VPN 
gateway; if the target address is already in use by some other 
VPN client, the gateway replies with a Neighbor Advertisement. 
If the target address is not already in use, the VPN gateway 
notes that it is now being used by this client and updates its 
forwarding state accordingly. 
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Comments: The main disadvantages of this solution are non-standard 
processing of NS messages (which are used to update the gateway’s 
forwarding state), and performing access control partly outside 
IPsec. 


A.6.3. Router Aggregation Sketch #2 


This is basically similar to the version -00 sketch described above 
but uses the router aggregation link model. In other words, it 
combines (1) the router aggregation link model, (2) prefix 
information distributed in Neighbor Advertisements, (3) unique 
address allocation with stateless address autoconfiguration (with the 
VPN gateway trapping NS messages and spoofing NA replies), and (4) 
access control enforced outside IPsec. 


1. During IKE_AUTH, the client sends a new configuration attribute, 
INTERNAL_IP6_LINK, which requests a virtual link to be created. 
The attribute contains the client's interface ID for the link- 
local address (other addresses may use other interface IDs). 


CP (CFG_REQUEST) = 
{ INTERNAL _ IP6_LINK(Link-Local Interface ID) ) 
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 


The VPN gateway replies with its own Link-Local Interface ID (which 
has to be different from the client’s) and an IKEv2 Link ID (which 
will be used for reauthentication). 


CP (CFG_REPLY) = 
{ INTERNAL IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) } 
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 


At this point, both peers configure the virtual interface with the 
link-local addresses. 


2. The next step is IPv6 stateless address autoconfiguration, that 
is, Router Solicitation and Router Advertisement messages sent 
over the IPsec SA. 
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ESP (Router Solicitation: 
src=::, 
dst=FF02:0:0:0:0:0:0:2) =-> 


<-- ESP (Router Advertisement: 
src=FE80::<Gateway’s Interface ID> 
dst=FF02:0:0:0:0:0:0:1, 
Prefixl, [Prefix2...]) 


3. The client now configures tentative unicast addresses from the 
prefixes given by the gateway and performs Duplicate Address 
Detection (DAD) for them. 


The Neighbor Solicitation messages are processed by the VPN 
gateway; if the target address is already in use by some other 
VPN client, the gateway replies with a Neighbor Advertisement. 
If the target address is not already in use, the VPN gateway 
notes that it is now being used by this client and updates its 
forwarding state accordingly. 


Comments: The main disadvantages of this solution are non-standard 
processing of NS messages (which are used to update the gateway’s 
forwarding state) and performing access control outside IPsec. 


A.6.4. IPv4-Like Sketch 


This sketch resembles the current IPv4 configuration payloads and 
combines (1) the router aggregation link model, (2) prefix 
information distributed in IKEv2 messages, (3) unique address 
allocation with IKEv2 messages, and (4) access control enforced by 
IPsec SAD/SPD. 


1. During IKE_AUTH, the client sends a new configuration attribute, 
INTERNAL_IP6_LINK, which requests a virtual link to be created. 
The attribute contains the client's interface ID for the link- 
local address (other addresses may use other interface IDs). 


CP (CFG_REQUEST) = 
{ INTERNAL IP6_LINK(Link-Local Interface ID) } 

TSi = (0, 0-65535, 
0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 

TSr = (0, 0-65535, 
0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 
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The VPN gateway replies with its own Link-Local Interface ID (which 
has to be different from the client’s), an IKEv2 Link ID (which will 
be used for reauthentication and CREATE_CHILD_SA messages), and zero 
or more INTERNAL_IP6_ADDRESS2 attributes. Each attribute contains 
one address from a particular prefix. 


CP (CFG_REPLY) = 
{ INTERNAL IP6_LINK(Link-Local Interface ID, IKEv2 Link ID), 
INTERNAL_IP6_ADDRESS2 (Prefix1l+Client’s Interface ID1), 
[INTERNAL _IP6_ADDRESS2 (Prefix2+Client’s Interface ID2),...], 
TSi = ((0, 0-65535, 
FE80::<Client’s Link-Local Interface ID> - 
FE80::<Client’s Link-Local Interface ID>) 
(0, 0-65535, 
Prefixl::<Client’s Interface ID1> - 
Prefixl::<Client’s Interface ID1>), 
[(0, 0-65535, 
Prefix2::<Client's Interface ID2> - 
Prefix2::<Client's Interface ID2>), ...]) 
TSr = (0, 0-65535, 
0:0:0:0:0:0:0:0 — 
FRFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 


Since the VPN gateway keeps track of address uniqueness, there is no 
need to perform Duplicate Address Detection. 


2. If the client wants additional addresses later (for example, with 
a specific interface ID), it requests them in a separate 
CREATE_CHILD_SA exchange. For example: 


CP (CFG_REQUEST) = 
{ INTERNAL _IP6_ADDRESS2 (Prefixl+Client’s Interface ID3) } 
TSi = (0, 0-65535, 
Prefix1::0 = 
Prefixl::FFFF:FFFF:FFFF:FFFF>), 
TSr = (0, 0-65535, 
0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 


If the requested address is not currently in use by some other 
client, the VPN gateway simply returns the same address and the 
appropriately narrowed traffic selectors. 
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CP (CFG_REQUEST) = 
{ INTERNAL IP6_ADDRESS2(Prefixl+Client's Interface ID3) } 

TSi = ((0, 0-65535, 
Prefixl::<Client’s Interface ID3> - 
Prefixl::<Client’s Interface ID3>), 

TSr = (0, 0-65535, 
0:0:0:0:0:0:0:0 — 
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 


Comments: The main advantage of this solution is that it’s quite 
close to the current IPv4 way of doing things. By adding explicit 
link creation (with Link ID for reauthentication/SPD selection and 
link-local addresses) and slightly changing the semantics (and also 
name) of the INTERNAL_IP6_ADDRESS attribute (which can return more 
attributes than was asked), we get much of the needed functionality. 


The biggest disadvantages are probably potentially complex 
implementation dependency for interface ID selection (see 
Section 3.3) and the multi-link subnet model. 


A.6.5. Sketch Based on RFC 3456 


For completeness: a solution modeled after [RFC3456] would combine 
(1) the router aggregation link model, (2) prefix information 
distribution and unique address allocation with DHCPv6, and (3) 
access control enforced by IPsec SAD/SPD. 
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Appendix B. Evaluation (Non-Normative) 


Section 3 describes the goals and requirements for IPv6 configuration 
in IKEv2. This appendix briefly summarizes how the solution 
specified in Sections 4 and 5 meets these goals. 


o 


(3.1) Assigning addresses from multiple prefixes is supported, 
without requiring the client to know beforehand how many prefixes 
are needed. 


(3.2) Link-local addresses are assigned and can be used for 
protocols between the VPN client and gateway. 


(3.3) The entire prefix is assigned to a single client, so the 
client can freely select any number of interface IDs (which may 
depend on the prefix). 


(3.4) This document does not specify how the VPN client would 
share the VPN connection with other devices. However, since the 
entire prefix is assigned to a single client, the client could 
further assign addresses from it without requiring coordination 
with the VPN gateway. 


(3.5) The solution does not add any new periodic messages over the 
VPN tunnel. 


(3.5) Reauthentication works (see Section 4.2). 


(3.5) The solution is compatible with other IPsec uses since the 
LINK_ID notification makes it unambiguous which CHILD_SAs are 
related to the virtual link and which are not (see Sections 4.3 
and 5.3). 


(3.5) The new mechanisms do not prevent the VPN client and/or 
gateway from implementing the INTERNAL_IP6_ADDRESS configuration 
attribute as well; however, the two mechanisms are not intended to 
be used simultaneously (see Section 4.5). 


(3.5) Implementation dependencies are, obviously, implementation 
dependent (and their cleanliness somewhat subjective). Possible 
drawbacks of some alternative solutions are discussed in 
Appendix A.6. 


(3.5) The mechanism for configuring the prefixes (configuration 
payloads) is specific to IKEv2, for reasons described in 
Appendix A. However, Section 4.1 recommends using DHCPv6 
Information-Request message for obtaining other configuration 
information (such as DNS server addresses). 
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